home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / MacApp Apr 91 / MacApp.Tech$ 4⁄19⁄91 / 3457-Re MacApp 3.0 vs C++-Apr91 < prev    next >
Encoding:
Text File  |  1991-04-29  |  2.4 KB  |  61 lines  |  [TEXT/GEOL]
  1. Item    0607196                         13-April-91        14:13PDT
  2.  
  3. From:   D2188                           Office Product Tech, B Toback,PRT
  4.  
  5. To:     CDA0542                         Serge Froment, Informagique,CAS
  6.         MACAPP.TECH$                    MacApp Technical
  7.  
  8. Item forwarded by       RON.METZKER  to EYES 
  9.  
  10. ------------------------------------------------------------------------------
  11.  
  12. Sub:    Re: MacApp 3.0 vs C++
  13.  
  14. Serge,
  15.  
  16. I haven't seen the rest of the traffic on your note, so this may be a repeat.
  17.  
  18. At the MADA conference, they showed some of the C++ code using MacBrowse. The
  19. code is eminently readable -- at least as good as the Pascal source if not
  20. better. It's well-commented, well-structured, uses the same names as the Pascal
  21. version, and has the same layout. In fact, when they first put the code on the
  22. screen, it took me a moment to realize that it was C++ rather than Pascal.
  23. Would that ALL C/C++ programmers did things that way!
  24.  
  25. There is only one obfuscation, having to do with nested procedures. They make
  26. up for that with a couple of clarifications. They've set up classes for common
  27. Macintosh types such as Point and Rect, and overloaded some of the normal
  28. operators. The comparison operators are particularly nice, since they makes
  29. possible constructs like
  30.  
  31.     if (currentPoint != oldPoint) ...
  32.  
  33. rather than calling EqualPt or comparing the coordinates explicitly.
  34.  
  35. Also, the error handling mechanism is now easier to follow in the source code,
  36. thanks to the use of several different constructs that make recovery code an
  37. explicit adjunct to the code that it protects. This makes it possible to use a
  38. TRY/RECOVER construct:
  39.  
  40.     TRY
  41.         stuff which might fail
  42.     RECOVER
  43.         what to do if it does fail
  44.     END_TRY
  45.  
  46. I noticed that you use THINK Pascal; I can see you might have a problem there.
  47. But Apple is introducing a debugger that looks as easy to use as the THINK
  48. debugger, and Zortech C++, while not Lightspeed, is (reportedly) at least fast
  49. enough to make C++ bearable. (And there's always The Debugger, which, since you
  50. don't live around Chicago, might be a good choice because of its incremental
  51. linker. (The Debugger is reportedly hard to use if you live around Chicago.)
  52. Again, not Lighspeed, but bearable.)
  53.  
  54. My advice is to wait and see what the MacApp folks have come up with before
  55. getting too depressed.
  56.  
  57. -- Bruce Toback
  58. OPT, Inc.
  59. AppleLink: D2188
  60.  
  61.